思考的問題

計算邏輯到底應該放哪裡？

當瞭解分層架構後，就會思考這麼多可以放置計算邏輯的位置，我應該放在哪裡？

常見程式分層的位置包含：前端、後端、Batch、Web API、Message Queue、資料庫端(Procedure、Function、Trigger)

前端計算

描述

將商業計算邏輯放置於前端，讓前端完成不需耗費大量資源的計算。

案例

• 傳統桌面應用程式：此模式的經典例子，在桌面應用程式中，大多數計算都是在使用者電腦端完成。
• 手機應用程式：在手機應用程式中，許多不須使用網路連線的功能，也可在手機端完成計算。
• Web應用程式：Web應用程式中，也可以使用JS在前端完成複雜的計算。例如：圖形辨識、產生Excel、PDF報表

優點

• 離線使用：若是通過洽當設計，這些只需要在前端計算的功能，可在沒有網路連線的環境下使用。
• 減輕伺服器負擔：將部分運算負擔由使用者端完成，這可以減少伺服器端的運算負擔及成本。
• 減少延遲：由於在使用者端完成計算，因此使用者不需等待網路傳輸

缺點

• 無法進行高負載運算：手機或是瀏覽器通常可使用的計算能力較低，桌面應用程式也無法達到雲端環境中平行運算的高效能結果。
• 不宜運算高機敏資料：由於使用者端的預算環境不受伺服器端控制，因此其運算的結果可能被偽造。不宜直接信任使用者端運行的結果。例如：可信任使用者傳來的商品數量，但是商品單價、消費金額 等資訊應該由後端計算。即使使用者端已經完成計算，伺服器端也需要進行驗證。
• 版本不一致問題：由於客戶端使用的不一定是最新版本應用程式，因此計算結果可能會有不一致的問題。

後端計算

描述

後端運算將計算邏輯搬移至伺服器

優點

• 減輕使用者系統負擔：某些使用者的硬體配備較差，將運算統一放置於伺服器端，可以給使用者更快速
• 進行高負載運算：由於伺服器端的資源較多，可由伺服器端完成 如資料辨識 等高負載運算
• 安全性、一致性的結果：計算結果統一於伺服器端完成，因此可信任計算結果，並且避免不同版本應用程式的資料不一致問題。

缺點

• 需網路連線：若計算需傳輸大量資料，會產生較高網路流量。對網路連線受限的使用者會造成負擔或使用體驗不佳。
• 伺服器負擔較重：若同時有大量使用者進行計算，需要通過水平擴展的方式處理使用者的計算請求，這需要更多的伺服器成本。

Batch

概述

Batch 程式是在伺服器端運行的一組程式，可以定時、手動或根據事件觸發執行。它常用於處理資料轉檔、報表產生和資料檢查等預先定義的任務清單。

使用情境

• 資料轉檔與檢查、產生報表
• 需耗費長時間執行的動作
• 須定時執行的動作

缺點

• 如果是較長時間執行的Batch程式往往會消耗較多系統資源
• 排程系統複雜: 由於各個Batch程式會在多個佇列中排隊執行，而不同程式的優先度與執行時間不一，若設計不當，往往會造成多個Job卡住。
• 以Batch形式進行的資料轉檔，由於並非即時轉檔，往往無法即時看到轉檔結果。現今架構較建議Real time進行資料串流處理。

Web API

概述

Web API以HTTP、HTTPS或其他Web介面來提供相關服務給外部客戶或內部其他系統。
常見身分認證機制包含：JWT、OAuth、SAML、API金鑰
認證成功後，資料交換時常見的格式包含：JSON、XML、CSV

使用情境

• 提供資源或服務: 內部系統、合作企業、客戶或是一般大眾
• 通訊與資料交換: 內部系統、合作企業、客戶
• 提供給其他應用程式呼叫，例如: 作為移動裝置的後端服務

優點

• 減少系統耦合度
• 提供標準化介面方便外部呼叫

缺點

• 安全性: 若通過公開網路傳送資料需要更注意資安議題，需透過HTTPS及身分認證等機制解決。
• 可能會有較大請求數量: 需透過水平擴展等機制以提供彈性的請求數量需求

Message Queue

概述:

Message Queue是一種常用於非同步處理邏輯的機制。當某個服務需要較長時間完成時，為了避免上游等待，可以將服務請求放入佇列中，按序等待執行。後方會有多個服務Consumer從佇列中取得服務請求並完成相應的處理。

一個典型的Message Queue架構包含三個主要元件：Message producer（產生服務請求的角色）、Message consumer（處理服務請求的角色）以及Message broker（負責訊息排序和呼叫consumer的角色）。

透過使用Message Queue，我們能夠實現1對多的通訊。Producer不需要知道後方有多少個consumer，只要有註冊相應事件的consumer都會接收到訊息。這樣的設計模式有效地解耦了producer和consumer之間的直接依賴關係，使系統更加靈活和擴展。

透過適當地應用Message Queue，我們能夠改善系統的可靠性和效能，特別適用於處理非同步處理需求的情境。

使用情境:

• 非同步事件驅動
• 非同步通信
• 日誌處理

優點:

• 避免前端等待: producer只要發出訊息請求後，即可完成動作。
• 低耦合: 可將一個大的服務拆成多個鬆散的小服務。且各個服務之間不需要直接通信，交由Broker轉交請求即可。
• 擴展性: 當等待中的請求較多時，可動態增加更多Consumer來處理服務請求。
• 平行處理: 如果有多個consumer註冊同一事件，可同步進行事件處理，而不須依序排隊執行。

缺點:

• 無法即時得知結果：由於訊息需等待broker轉發。所以producer若需等待結果，則需要追蹤此訊息處理的狀態。

DB Procedure

概述:

DB Procedure是存放於資料庫的程式，通常是以SQL為核心，搭配變數、邏輯判斷、迴圈的程式，以達到於資料庫高效處理資料的目的。

優點

• 在資料庫端即可處理複雜的資料處理，有效的處理大量資料，避免網路延遲與資料傳輸量的問題
• 在資料庫端處理，可以更方便的處理事務(Transaction)管理

缺點

• 難以除錯與開發: 較難設定中斷點、記錄程式運行的Log、也較少方便、提供程式碼提示的編輯器。
• 基於程式架構的原因，難以使用現代的程式概念，例如: 物件導向。
• 耦合度較高: 由於程式都是在資料庫中，程式之間以及程式與資料表之間的耦合度很高。
• 較難更新程式: 更新DB Procedure與資料表時容易造成相關連物件的錯誤。難以達到zero down time的程式更新。
• 程式綁定特定資料庫，難以遷移至其他資料庫產品。

案例

• PL/SQL: Oracle資料庫的DB Proecdure
• T-SQL: SQL Server資料庫的DB Proecdure

DB Function

描述

DB Function是在DB端的一種程式，按照資料庫種類的語法會不一樣，例如PL/SQL, T-SQL。
如同一般程式Function，取得傳入值並進行邏輯處理後，回傳結果。

與DB Procedure的差異

• 可以在SQL中使用
• 通常不能在DB Function中異動資料

使用情境

• 在SQL中，抽出重複性的子查詢指令
• 在SQL中，撰寫需有較複雜程式處理的邏輯

DB Trigger

描述

DB Trigger是在DB端的一種程式，按照資料庫種類的語法會不一樣，例如PL/SQL, T-SQL。
使用目的為監控特定資料表資料的異動，在資料新增、修改、刪除時執行特定邏輯。

使用情境

• 紀錄異動Log
• 連動更新相關資料表
• 同步刪除關聯資料表的資料

優點

• 可以在資料庫端實作Event Driven的邏輯: 事件發生時，自動執行預定義的邏輯

缺點

• 使用過多會降低資料庫效能
• 須注意不同資料表之間的Trigger不會無限循環觸發